
╔═════════╦════════════════════════════════════════════════════════════
║ GT-HELP ║ Redirection in Doors
╚═════════╩════════════════════════════════════════════════════════════


If the program you are running in the door was written specifically 
for that purpose, it will be able to take its input from the comms port 
and display its output to the comms port.  Such a program will probably
also display locally so you can see what is going on, and may even allow
you to enter input in the same way that you can do for GT.  Hopefully
such a program will come with instructions on how to set it up.

Most programs are written to expect input from the keyboard, and they 
expect to display their output to the screen.  But you may be able to 
run them in a door if you can redirect their input and output.


┌──────────────────────┐
│ Redirecting via CTTY │
└──────────────────────┘

    Redirection is often performed by the dos CTTY command - though 
    usually you won't see it in the batch file since GT sets the first DOS
    parameter to CTTY and it is referenced as %1 in the batch file :

        %1 COM%2
        ...
        ... command(s) to execute
        ...
        %1 CON

    CTTY will only succesfully redirect a program which takes input via 
    the "standard input" and writes to "standard output".  It will not
    redirect a program which writes directly to screen.
    
    It works in many cases, but ...
    
    a)  It will not work if the machine is running Desqview (or maybe 
        other multitaskers).
    
    b)  Some modems do things that prevent CTTY from working (especially
        at lower speeds, like V21 and V23).
    
    c)  There is no XON/XOFF support, and input and output are virtually 
        unbuffered.  So characters can be lost, especially at higher 
        speeds.
    
    d)  There is no way for the sysop to find out what is going on.
        The sysops screen and keyboard will be dead throughout.
        
        Hint:   put 
        
                    ECHO In a Door! 
                
                at the front of your batch file so that at least you 
                know the machine hasn't died.
    

┌─────────────────────────────────┐
│ Redirection using fossil driver │
└─────────────────────────────────┘

    A fossil driver such as X00 may make CTTY usable in cases where 
    CTTY loses characters or drops the line altogether.  A fossil
    generally provides buffering to ensure characters are not lost,
    and can also provide XON/XOFF support.  It will also check for
    lost carriers.  Look for X00*.* on a board with a good comms file 
    area.
  
  
┌───────────────────────────┐
│ IBMAUX / Gateway / Others │
└───────────────────────────┘

    These programs copy the line output to the screen, so that at least 
    you can see what is happening.  Some of them also allow you to enter
    keystrokes.
    

┌──────────────────────────┐
│ Marshal Dudley's Doorway │
└──────────────────────────┘

    This will in most cases allow you to run programs which write direct
    to screen, and probably does almost everything else that you need in
    a door.  Look for DRWY*.*


╔═════════════════════════════════════╗
║ Doorman - Carrier Detect Monitoring ║
╚═════════════════════════════════════╝

    In doors, you should normally also run DOORMAN.  This is a TSR which 
    periodically samples the carrier and reboots the machine if the 
    carrier is lost.

    Doorman needs to be loaded prior to executing GT -- usually either in
    autoexec.bat or HOST.BAT.

    If you do not run doorman and the caller loses carrier during a door,
    then it is likely that the board will hang.   Or possibly the next
    caller could continue using the previous caller's logon identity which
    is a security risk.


┌───────────────────────────────────────┐
│ DVDOOR - Time monitoring for DV users │
└───────────────────────────────────────┘

    When running in desqview, its not a good idea to have the machine 
    reboot when a caller overruns time.  DVDOOR (Ken Thompson) monitors 
    time but not carrier, and terminates an overrunning program rather 
    than rebooting.  You need to use it with a door program that 
    monitors carrier and terminates, rather than one which reboots.
    
    Look around for DVD*.* 
    

╔══════════╗
║ Security ║
╚══════════╝

    Unless the program you are running is going to be restricted to your 
    own access level, make sure the program doesn't offer the caller any
    facilities to shell out to DOS, edit or transmit arbitrary files, or 
    similar.
    
    Check also that it will :
    
    a)  Recover from a lost carrier while in a door
    
    b)  Not allow callers to stay on past their time limit
    
    c)  Not do anything inappropriate on receipt of ^C.
    

╔══════════╗
║ Problems ║
╚══════════╝

    The GT support echo is a good place to describe any problems.  
    Usually somebody who has done it before will tell you how.
    


